feat(normalize): render post attachment zone in convertPost - #18

The rich-text attachment zone (top-level files array) was ignored by the
post converter: only the locale document (title/content) was flattened
and scanned for resources, so attachments attached to a rich-text message
were invisible to channel consumers.

- render attachment-zone files as <file key=... name=.../> lines and
  is_folder entries as <folder .../> lines, matching the standalone
  file/folder converters
- surface attachment-zone files as ResourceDescriptor(type=file) so they
  are downloadable; folders remain tag-only like the folder converter
- cover with tests: rendering + resource extraction, empty files array

…lues

Follow-up fixes on top of the attachment-zone support, covering paths the
original change left untested:

- Read the attachment zone before the locale guard. `files` is a sibling of
  the locale documents, not part of one, so a post whose locale document
  cannot be unwrapped was silently dropping its attachments entirely.
- Normalize entries in `topLevelAttachments` instead of casting the raw wire
  record. A non-string `file_name` reached `escapeAttr` and threw, which
  `dispatchConvert` traps by falling back to the unknown-message converter —
  replacing the entire message, body and all, with a placeholder.
- Compare `is_folder` against `true` rather than testing truthiness, so a
  string `"false"` cannot hide a real, downloadable file behind a `<folder/>`
  tag and drop it from `resources`.
- Escape the key as well as the name when rendering tags, matching how these
  tags are produced elsewhere.

The narrowed `PostAttachment` type now states what the extractor actually
guarantees, which removes the redundant empty-key check and the duplicated
attribute construction in the render loop.

Adds regression tests for each path, plus an ordering assertion the existing
`toContain` checks could not make.